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Abstract. When implementing a propagator for a constraint, one must 
decide about variants: When implementing min, should one also imple- 
ment max? Should one implement linear equations both with and with- 
out coefficients? Constraint variants are ubiquitous: implementing them 
requires considerable (if not prohibitive) effort and decreases maintain- 
ability, but will deliver better performance. 

This paper shows how to use variable views, previously introduced for 
an implementation architecture, to derive perfect propagator variants. A 
model for views and derived propagators is introduced. Derived propaga- 
tors are proved to be indeed perfect in that they inherit essential proper- 
ties such as correctness and domain and bounds consistency. Techniques 
for systematically deriving propagators such as transformation, gener- 
alization, specialization, and channeling are developed for several vari- 
able domains. We evaluate the massive impact of derived propagators. 
Without derived propagators, Gecode would require 140 000 rather than 
40 000 lines of code for propagators. 



1 Introduction 

When implementing a propagator for a constraint, one typically needs to decide 
whether to also implement some of its variants. For example, when implementing 
a propagator for max™ =1 Xi = y, should one also implement min" =1 Xi = yl When 
implementing the linear equation Y^i=i aiXi ~ c f° r integer variables a;, and 
integers <Zj and c, should one also implement x i = c f° r better performance? 

When implementing the reified linear equation (X)"=i x i = c ) ^ should one 
also implement its almost identical algebraic variant (527=1 x i c ) ^ bl 

Implementing inflates code and documentation. Not implementing increases 
space and runtime: by using more general propagators or by decomposing into 
several other constraints. Worse, given the potential code explosion, one may be 
able to only implement some variants (say, minimum and maximum) . Other vari- 
ants important for performance (say, minimum and maximum for two variables) 
may be infeasible due to excessive programming and maintenance effort. 

Here, we follow a third approach: we derive propagators from already exist- 
ing propagators using variable views. In [12], we introduced an implementation 
architecture for variable views to reuse generic propagators without performance 
penalty. This architecture has been implemented in Gecode [5], and is in fact 
essential for the system, as it saves approximately 100 000 lines of code. Due to 



the massive use of views in Gecode, it is vital to develop a model that allows us 
to prove that derived propagators have the desired properties. 

In this paper, we argue that propagators that arc derived using variable views 
are indeed perfect: they are not only perfect for performance, we prove that they 
inherit all essential properties such as correctness and completeness from their 
original propagator. 

Last but not least, we show common techniques for deriving propagators with 
views and demonstrate their wide applicability. In Gecode, every propagator 
implementation is reused 3.6 times on average. Without views, Gecode would 
feature 140 000 rather than 40 000 lines of propagator implementation to be 
written, tested, and maintained. 

Variable views. Consider a bounds consistent propagator for max(x,y) = z. 
Assume that x (x) returns the maximum (minimum) of the finite domain variable 
x, whereas x <— n (x <— n) adjusts the maximum (minimum) value of x to 
min(x, n) (max(x, n)), only taking variable bounds into account. The propagator 
is implemented by performing the following operations on its variables: 

x <^~z y <— z z <— max(x, y) z +— max(x, y) 

Given three more propagators for x' = —x, y' = —y, and z' = —z, we could 
propagate the constraint min(x',y') = z'. In contrast to this decomposition, 
we propose to use generic propagators that perform operations on views rather 
than variables. Views provide the same interface (set of operations) as variables 
while enabling additional transformations. For example, an operation on a minus 
view x' on a variable x behaves as if executed on — x: x' is defined as — x and 

x 1 <— n is defined as x < n. With views, the implementation of the maximum 

propagator can be reused: we derive a propagator for the minimum constraint 
by instantiating the maximum propagator with minus views for its variables. 

The feasibility of variable views rests on today's programming languages' 
support for generic (or polymorphic) constructions (for example, templates in 
C++) and that the simple transformations provided by views are optimized away. 

Contributions. This paper contributes an implementation independent model 
for views and derived propagators, techniques for deriving propagators, and an 
evaluation that shows that views are widely applicable, drastically reduce pro- 
gramming effort, and are more efficient than decomposition. 

More specifically, the key contribution is the identification of properties of 
views that are essential for deriving perfect propagators. To this end, the pa- 
per establishes a formal model that defines a view as a function and a derived 
propagator as functional composition of views (mapping values to values) with a 
propagator (mapping variable domains to variable domains). This model yields 
all the desired results: derived propagators are indeed propagators; derived prop- 
agators faithfully implement the intended constraints; domain consistency carries 
over to derived propagators; different forms of bounds consistency over integer 
variables carry over provided that the views satisfy additional properties. 
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After establishing the fundamental results, we address further properties of 
derived propagators such as idempotence, subsumption, and events. Finally, we 
clarify the connection between derived propagators and path consistency when 
regarding views as binary constraints. 

Wc introduce techniques for deriving propagators that use views for special- 
ization and generalization of propagators, channeling between variable domains, 
and general domain-specific transformations. We show how to apply these tech- 
niques for different variable domains using various views. We provide a break- 
down of how successful the use of derived propagators has been for Gecode. 

Overview. The next section introduces the basic notions we will use. Sect. 3 
presents views and derived propagators and proves fundamental properties like 
correctness and completeness. The following three sections develop techniques for 
deriving propagators: transformation, generalization, specialization, and chan- 
neling. Sect. 7 presents extensions of the model, and Sect. 8 discusses its limita- 
tions. Sect. 9 provides empirical evidence that views are useful in practice. 

2 Preliminaries 

This section sets the stage for the paper with definitions of the basic concepts. 

Variables and constraints. We assume a finite set of variables Var = 
{x\, . . . ,x n } and a finite set of values Val. Constraints are characterized by 
assignments a G Asn that map variables to values: Asn = Var — > Val. A 
constraint c G Con is a relation over the variables, represented as the set of 
all assignments that satisfy the constraint, Con = 2 Asn . We base constraints 
on full assignments, defined for all variables in Var. However, for typical con- 
straints, only a subset vars(c) of the variables is significant; the constraint 
is the full relation for all x $ vars(c). Wc write a constraint in extension 
(c = { [x i — > 0, y i — ► 1), (x h > 2)}) or intensionally (c = x < y). 

Domains. Constraints are implemented by propagators over domains, which 
are constructed as follows. A domain d € Dom maps each variable to a finite set 
of possible values, the variable domain d(x) C Val. 

A domain d can be identified with a set of assignments d G 2 Asn . We can 
therefore treat domains as constraints. In particular, for any assignment a, {a} 
is a domain as well as a constraint. We simply write domain for domains and 
variable domains when there is no risk of confusion. 

A domain d\ is stronger than a domain di (written d\ C d 2 ), iff for all 
variables x, d\(x) C d,2(x). By dom(c) we refer to the strongest domain including 
all valid assignments of a constraint, defined as min{<i G Dom c C d} — 
{a | \/x 3b G c. a(x) = b(x)}. The minimum exists as domains are closed under 
intersection, and the definition is non-trivial because not every constraint can 
be captured by a domain. Now, for a constraint c and a domain d, dom(c n d) 
refers to removing all values from d not supported by the constraint c. 
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Propagators. Propagators serve here as implementations of constraints. They 
are sometimes also referred to as constraint narrowing operators or filter func- 
tions. A propagator is a function p G Dom — > Dom that is contracting (p(d) C d) 
and monotone (d! C d =>■ p(d') C p{d)). Idcmpotence is not required. 

Propagators are contracting, they only remove values from variable domains. 
For an assignment a, a propagator p hence has only two options: accept it 
(p({a}) = {a}), or reject it (p({a}) = 0). Monotonicity guarantees that if some 
domain d contains an assignment a G d that p accepts, then p will not remove a 
from d: a G p(d) . The propagator therefore behaves like a characteristic function 
for the set of accepted assignments. This set is the associated constraint of p. 

We say that a propagator p implements its associated constraint c p = {a G 
Asn | p({a}) = {a}}. Monotonicity implies that for any domain d, we have 
dom(c p (~l d) C p{d): no solution of c p is ever removed by p. We say that p 
is sound for any c C c p and weakly complete for any c' 2 c P (meaning that 
it accepts all assignments in c and rejects all assignments not in c'). For any 
constraint c, we can find at least one propagator p such that c = c p . Typically, 
there are several propagators, differing by propagation strength (see Sect. 3). 

Our definitions of soundness and different notions of completeness for prop- 
agators are based on and equivalent to Benhamou's [2] and Maher's [9]. We 
specify what is computed by constraint propagation and not how. Approaches 
for performing constraint propagation can be found in [2, 1, 11]. 

3 Views and Derived Propagators 

We now introduce our central concepts, views and derived propagators. 

A view on a variable x is an injective function tp x G Val — * Val , mapping 
values from Val to values from a possibly different set Val'. We lift a fam- 
ily of views cp x (one for each x G Var) point-wise to assignments as follows: 
l PAsn{o J ){x) = <p x (a(x)). Finally, given a family of views lifted to assignments, 
we define a view ip G Con — > Con on constraints as y(c) = {<pAsn{a<) I a £ c }- 
The inverse of that view is defined as <pT (c) = {a G Asn | ipAsnip) G c}. 

In the implementation, a view on x presents the same interface as x, but 
applies transformations when a propagator adjusts or accesses the domain of x 
through the view. In our model, ip performs the transformations for accessing, 
and Lp~ for adjusting the variable domains. Views can now be composed with a 
propagator: a derived propagator is defined as (p(p)(d) = tp~ (p(ip(d))) , or, using 
function composition, as (p(p) = (f~ op o ip. 

Example. Given a propagator p for the constraint c = (x = y), we want to 
derive a propagator for d = (x = 2y) using a view ip such that <p~(c) = c! . 

It is usually easier to think about the other direction: ip{c') C c. Intuitively, 
the function ip leaves x as it is and scales y by 2, while ip~ does the inverse 
transformation. We thus define tp x (v) = v and tp y {v) = 2v. We have a subset 
relation because some tuples of c may be ruled out by (p. For instance, with (p 
defined as above, there is no assignment a such that (pAsn{a<){y) = 3, but the 
assignment (x \— > 3, y t— > 3) is in c. 
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This example also makes clear why the set Vol' is allowed to differ from Vol. 
In this particular case, Vol' has to contain all multiples of 2 of elements in Vol. 

The derived propagator is <f(p) = p~ op o ip. We say that p(p) "uses a scale 
view on" y, meaning that p y is the function defined as f v (v) = 2v. Similarly, 
using an identity view on x amounts to p x being the identity function on Vol. 

Given the assignment a = (x i— ► 2,z/ i— > 1), we first apply ipAsn and get 
tfiAsnia) = (x > 2,y i— > 2). This is accepted by p and returned unchanged, 
so p" transforms it back to a. Another assignment, a' = (x i— ► 1, y i— > 2), is 
transformed to fAsn 

(a') = (x >-> l,y >-> 4), rejected (p({^ S n(a')}) = 0)i and 
the empty domain is mapped to the empty domain by p~ . The propagator tp(p) 
implements p~(c). □ 

Views and derived propagators satisfy a number of essential properties: 

1. A derived propagator (p(j)) is in fact a propagator. 

2. The associated constraint of >fi(p) is ip~(c p ). 

3. A view if preserves contraction of a propagator p: If p(ip(d)) C </s(d), then 
(p(p)(d) C d. This property makes sure that if the propagator makes an 
inference, then this inference will actually be reflected in a domain change. 

In the following, we will prove these properties. For the proofs, we employ some 
direct consequences of the definitions of views and derived propagators: (1) (p 
and ip~~ are monotone by construction; (2) ip~ oip — id (the identity function); (3) 
^(l -})! = 1; = (4) f° r an Y view if and domain d, we have if(d) G Dom 
and f~(d) S Dom (as views are defined point-wise). 

Theorem 1. A derived propagator is a propagator: for all propagators p and 
views if, <f(p) is a monotone and contracting function in Dom Dom. □ 

Proof. The derived propagator is well-defined because both f(d) and ip~ (d) are 
domains (see (4) above). Monotonicity is obvious, as compositions of monotone 
functions are monotone. For contraction, we have p(ip(d)) C ip(d) as p is con- 
tracting. By monotonicity of ip~ , we know that tp~ (p(tp(d))) C ip~(ip(d)). As 
ip~ o if = id, we have p~{p{p{d))) C d, which proves that if(p) is contracting. In 
summary, for any propagator p, p{p) = f~ o p o p is a propagator. ■ 

Theorem 2. If p implements c p , then <^(p) implements f~{c p ). p 

Proof. As p implements c p , we know p({a}) = c p (~l {a} for all assignments a. 
With |<^({a})| = 1, we have p(f({a})) = c p D f({a}). Furthermore, we know 
that c p fl f({a}) is either or p({a}). Case 0: We have p~ (p(p({a}))) = = 
{a} n f~(c p ). Case p({a}): As tp~ o p = id, we have p~ (p(p({a}))) = {a}. 
Furthermore: 

c p n f({a}) — f({a}) => 3b e Cp. b ~ p(a) 

=> a G {a' G ^4sn | <^(a') G c p } => a G (y5~(c p ) 

Together, this shows that p~ o p o <^({a}) = {a} fl <y9 _ (c p ). ■ 
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Theorem 3. Views preserve contraction: for any domain d, if p(ip(d)) C ip(d), 
then (p{p)(d) C d. □ 



Proof. Recall the definition of <p~(c) as {a G Asn \ ipAsn( a ) G c }- It clearly 
follows that <p~(c)| < |c|. Similarly, we know that \<p(c)\ = \c\. From p(ip(d)) C 
93(d), we know that \p(ip(d))\ < \<p(d)\. Together, this yields \ip(p)(d)\ < \<p(d)\ = 
\d\. We have already seen in Theorem 1 that (p(p)(d) C d, so we can conclude 
that (p(jp){d) C d. m 

Completeness. Weak completeness, as introduced above, is the minimum re- 
quired for a constraint solver to be complete. A weakly complete propagator does 
not have to prune variable domains, it only has to check if an assigned domain 
is a solution of the constraint. The success of constraint propagation however 
crucially depends on strong propagators that prune variable domains. 

The strongest possible inference that a single propagator can do establishes 
domain consistency (also known as generalized arc consistency): a domain d 
is domain consistent for a constraint c, iff for all variables x t and all values 
vi G d(xi), there exist values Vj G d(xj) for all other variables Xj such that the 
assignment (x\ 1— ► V\, . . . , Xi <— ► v^, . . . , x n 1— ► v n ) is a solution of c. 

A propagator is domain complete (or simply complete) for a constraint c if 
it establishes domain consistency. More formally, a propagator p is complete for 
a constraint c iff for all domains d, we have p(d) C dom(c H d). A complete 
propagator thus removes all assignments from d that are inconsistent with c. 

We will now prove that propagators derived from complete propagators are 
also complete. In Sect. 5, wc will extend this result to weaker notions of com- 
pleteness, such as bounds(Z) and bounds(R) completeness. 

For this proof, we need two auxiliary definitions. A constraint c is a tp con- 
straint iff for all a G c, there is a b G Asn such that a = (pAsn{b)- A view ip is 
dom infective iff tp~(dom(c)) = dom(ip~(c)) for all ip constraints c. 

For the completeness proof, we need a lemma that states that any view is 
dom injective. 

Proof. By definition of p~ and dom(-), we have < / 9 _ (dom(c)) = {a G 
Asn I Vx. 36 G c.(y9 J 4 s „(a)(x) = 6(s)}. As c is a 95 constraint, wc can find such 
a b that is in the range of <pAsn, if and only if there is also a b' G </S~(c) such 
that <fAsnip') = b. Therefore, we get {a G ^sn | Vx.36' G iy3~ (c).a(x) = b' (x)} = 
dom(ip~(c)). m 

Furthermore, we need a lemma that states that views commute with set 
intersection: For any view ip, the equation p~{c\ (~l C2) = 9? - (ci) n p~(c2) holds. 

Proof. By definition of tp~ , we have v? - (ci n C2) = {a G ;4sn | 99 Asn(a) G 
Ci A <y5yisM(a) G C2}. As lyS^sn is a function, this is equal to {a G ^4sn | tpAsn(a) G 
ci} n {a G ^4sn I ipAsn(a) S c 2 } = ^ _ ( c i) H ^~( c 2)- ■ 

Theorem 4. If p is complete for c, then (j5(p) is complete for p~(c). □ 
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Proof. By monotonicity of tp and completeness of p, we know that (p~ opcnp(d) C 
Lp~ (dom(cn <p(d))) . We now use the fact that ip~ is dom injective and commutes 
with set intersection: 

ip~ (dom(c n ip(d))) = dom((/3 _ (c n <p(d))) = 
dom((p~ (c) n ip~ (<p(d))) = dom(</3 _ (c) n d) ■ 



4 Boolean Variables: Transformation 

This section discusses views and derived propagators for Boolean variables where 
Val = {0, 1}. Not surprisingly, the only view apart from identity for Boolean 
variables captures negation. That is, using a negation view on x defines tp x (v) = 
1 — v for x G Var and V G Val. 

Negation views are more widely applicable than one would initially believe. 
They demonstrate how views can be used systematically to obtain implementa- 
tions of constraint variants by transformation. 

Boolean connectives. The immediate application of negation views is to derive 
propagators for all Boolean connectives from just three propagators: A negation 
view for x in x — y yields a propagator for —tx = y. From disjunction x\/y = z one 
can derive conjunction x A y = z with negation views on x, y, z, and implication 
x —y y = z with a negation view on x. From equi valence x «-» y — z one can 
derive exclusive or x y = z with a negation view on z. 

As Boolean constraints are widespread in models, it pays off to optimize fre- 
quently occurring cases. One important propagator is disjunction V™=i x % = V 
for arbitrarily many variables; again conjunction can be derived with negation 
views on the Xi and on y. Another important propagator is for the constraint 
V"=i Xi = 1> stating that the disjunction must be true. A propagator for this 
constraint is essential as the constraint occurs frequently and as it can be im- 
plemented efficiently using watched literals, see for example [6]. With views and 
derived propagators all implementation work is readily reused for conjunction. 
This shows a general advantage of views: effort put into optimizing a single 
propagator directly pays off for all other propagators derived from it. 

Boolean cardinality. Like the constraint VlLi x * ~ 1> ^ ne Boolean cardinality 
constraint X)"=i x * — c occurs frequently and can be implemented efficiently 
using watched literals (requiring c + 1 watched literals, Boolean disjunction cor- 
responds to the case where c = 1). But also a propagator for Yn=i Xi — c can 
be derived using negation views with the following transformation: 

i= i Xi <c - 2^ i=1 x t > -c n - }^ i=1 Xi>n-c 

Yh=i 1 ~ x i >n-c Yh=i ^Xi>n-c 
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Reification. Many reified constraints (such as (Y^—i x i — c ) & b) also exist in 
a negated version (such as (X)"=i x i c ) ^ Deriving the negated version is 
trivial by using a negation view on the Boolean control variable b. This contrasts 
nicely with the effort without views: either the entire code must be duplicated or 
the parts that perform checking whether the constraint or its negation is entailed 
must be factorized out and combined differently for the two variants. 

5 Integer Variables: Generalization, Bounds Consistency, 
Specialization 

Common views for finite domain integer variables capture linear transformations 
of the integer values. In [12], the following views are introduced for a variable 
x and values v: a minus view on x is defined as tp x (v) = —v, an offset view for 
o G Z on x is defined as <p x (v) = v + o, and a scale view for a G Z on x is defined 
as ip x {v) = a ■ v. 

Propagators for integer variables offer a greater degree of freedom concern- 
ing their level of completeness. While Boolean propagators most often will be 
domain complete, bounds completeness is important for integer propagators. Be- 
fore we discuss transformation and generalization techniques for deriving integer 
propagators, we study how bounds completeness is affected by views. 

Bounds consistency and bounds completeness. There are several different 
notions of bounds consistency in the literature (see [4] for an overview). For our 
purposes, we distinguish bounds(P), bounds(Z), and bounds (R) consistency: 

— A domain d is bounds(P) consistent for a constraint c, iff for all variables Xi 
there exist Vj G d(xj) for all other variables Xj such that {x\ i— ► v\, . . . , Xi i— ► 
mm(d(xi)), . . . , x n i— ► v n } G c and analogously for Xi \— > max(d(xj)). 

— A domain d is bounds (Z) consistent for a constraint c, iff for all variables 
Xi, there exist integers Vj with min(d(xj)) < Vj < m&x(d(xj)) for all other 
variables Xj such that {x\ i— ► v\, . . . , Xi t— » min(d(o;j)), . . . , x n t— * v n } G c and 
analogously for xt i— > max(d(a;i)). 

— A domain d is bounds (R) consistent for a constraint c, iff for all variables 
.Ti, there exist real numbers Vj G R with min(<i(a;j)) < < max.(d(xj)) for 
all other variables Xj such that {.ti i— > v-y,...,Xi <— > min(d(xj)), . . . , x„ i— > 

G cr and analogously for Xj i— > max(d(xi)), where cr is c relaxed to R 
(for constraints like arithmetics where relaxation makes sense). 

A propagator p is bounds (A) complete for its associated constraint c p , 
iff p{d) is bounds(A) consistent for c p for every domain d that is a fix- 
point of p. We use an equivalent definition based on the strongest con- 
vex domain that contains a constraint, conv(c) = min{c? G Dom \ c C 
d and d convex}. A convex domain maps each variable to an interval, so that 
conv(c)(x) = {min agc (a(x)), . . . , max agc (a(x))}. Note that conv(c) is weaker 
than the strongest domain that contains c: conv(c) D dom(c) for all constraints 
c. In the same way as Bcnhamou [2] and Maher [9] , we define 
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— p is bounds(2?) complete for c iff p(d) C conv(c D d). 

— p is bounds(Z) complete for c iff p(d) C conv(cn conv(d)). 

— p is bounds(R) complete for c iff p(<i) C conv(cRnconvR(e?)), where convR(c?) 
is the convex hull of d in R, and cr is c relaxed to R. 

Bounds completeness of derived propagators. Theorem 4 states that prop- 
agators derived from domain complete propagators are domain complete. A sim- 
ilar theorem holds for bounds completeness, if views commute with conv(-) in 
the following ways: 

A view tp is interval injective iff tp~ (conv(c)) = conv(<p - (c)) for all tp con- 
straints c. It is interval bijective iff it is interval injective and tp(conv(d)) = 
conv(tp(d)) for all domains d. 

Proving bounds completeness of derived propagators is now similar to proving 
domain completeness. We only formulate bounds(Z) completeness. 

Theorem 5. If p is bounds(Z) complete for c and tp is interval bijective, then 
(p(p) is bounds(Z) complete for tp(c). □ 

Proof. By monotonicity of (p and bounds (Z) completeness of p, we know that 
tp~ opotp(d) C iy9~(conv(c fl conv(<^(d)))). We now use the fact that both tp and 
tp~ commute with conv and intersection: 

tp(conv(c fl conv(<y9 _1 (<i)))) = <^(conv(c H tp -1 (conv (d)))) = 
conv(p(c fl tp~ x (conv (d)))) = conv (tp(c) H p(p -1 (conv (d)))) = 

conv(ip(c) fl conv(d)) ■ 

The proof for bounds(P) is analogous, but we only require interval injectivity 
for the view. With an interval injective view, one can also derive bounds(R) com- 
plete propagators from bounds(R) or bounds(Z) complete propagators. Table 1 
summarizes how completeness depends on view bijectivity. 



Table 1. Completeness of derived propagators 



propagator 


view 


interval bijective 


interval injective 


arbitrary 


domain 
bounds(X') 
bounds(Z) 
bounds(R) 


domain 
bounds(P) 
bounds(Z) 
bounds(R) 


domain 
bounds(X>) 
bounds(R) 
bounds(R) 


domain 
weakly 
weakly 
weakly 



The views for integer variables presented at the beginning of this section have 
the following properties: minus and offset views are interval bijective, whereas a 
scale view for a € Z on x is always interval injective and only interval bijective 
if a = I or a = — I (in which cases it coincides with the identity view or a minus 
view, respectively). An important consequence is that a bounds (Z) complete 
propagator for the constraint £^ Xi = c, when instantiated with scale views for 
the Xi, results in a bounds(R) complete propagator for J2i a i x % = c - 
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Transformation. Like the negation view for Boolean variables, minus views for 
integer variables help to derive propagators following simple transformations: for 
example, min(x, y) = z can be derived from max(a;, y) — z by using minus views 
for x, y, and z. 

Transformations through minus views can improve performance in subtle 
ways. Consider a bounds(Z) consistent propagator for multiplication x x y = 
z. Propagation depends on whether zero is still included in the domains of x, 
y, or z. Testing for inclusion of zero each time the propagator is executed is 
not very efficient. Instead, one would like to rewrite the propagator to special 
variants where x, y, and z are either strictly positive or negative. These variants 
can propagate more efficiently, in particular because propagation can easily be 
implemented to be idempotent (see Section 7). Implementing three different 
propagators (all variables strictly positive, x or y strictly positive, only z strictly 
positive) seems excessive. Here, a single propagator assuming that all views are 
positive is sufficient, the others can be derived using minus views. 

Generalization. Offset and scale views are useful for generalizing propagators. 
Generalization has two key advantages: simplicity and efficiency. A more spe- 
cialized propagator is often simpler to implement than a generalized version. 
The possibility to use the specialized version when the full power of the general 
version is not required may save space and time during execution. 

The propagator for a linear equality constraint X)"=i x% ~ cis efficient for the 
common case that the linear equation has only unit coefficients. The more general 
case X)™=i a i x i = c can b e derived by using scale views for dj on Xi (This of 
course also holds true for linear inequality and discquality rather than equality). 
Similarly, a propagator for alldiffcrent(a;i) can be generalized to alldiffercnt(ci + 
Xi) by using offset views for c, £ Z on ij. Likewise, a propagator for the element 
constraint (ci, . . . , c n ) [x] = y can be generalized to (ci, . . . , c n ) [x + o] = y with 
an offset view, where o £ Z provides a useful offset for the index variable x. 
It is important to recall that propagators are derived: in Gecode, the above 
generalizations are applied to domain as well as bounds complete propagators. 

Specialization. We employ constant views to specialize propagators. A con- 
stant view behaves like a fixed variable. In practice, specialization has two ad- 
vantages: Fewer variables are needed, which means less space consumption. And 
specialized propagators can be compiled to more efficient code, if constants are 
known at compile time. 

Examples for specialization are a propagator for binary linear inequality x + 
y < c derived from a propagator for x + y + z < cby using a constant for 
z; a Boolean propagator for x A y 1 from x A y <-*■ z and constant 1 for 
z; a propagator for the element constraint (c±, . . . , c„) [y] = z derived from a 
propagator for (x\, . . . ,x n ) [y] = z; a reified propagator for (x = c) <-> b from 
(x — y) <-> b and a constant c for y; a propagator for counting \{i | xi = y}\ = c 
from a propagator for |{z | x% = y} \ = z\ and many more. 

We have to extend our model to support constant views. Propagators may 
now be defined with respect to a superset of the variables, Var' D Var. A 
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constant view for the value k on a variable z 6 Var \ Var translates between 
the two sets of variables as follows: 

<p~(c) = {a\ Var aec} 
<p(c) = {a[k/z} | a G c} 

Here, a[k/z] means augmenting the assignment a so that it maps z to k, and 
a | var is the functional restriction of a to the set Var. It is important to see that 
this definition preserves failure: if a propagator returns a failed domain d that 
maps z to the empty set, then f~(d) is the empty set, too. 

Indexicals. Views that perform arithmetic transformations are related to in- 
dcxicals [3, 13]. An indexical is a propagator that prunes a single variable and is 
defined in terms of range expressions. A view is similar to an indexical with a 
single input variable. However, views are not used to build propagators directly, 
but to derive new propagators from existing ones. Allowing the full expressivity 
of indexicals for views would imply giving up our completeness results. 

Another related concept are arithmetic expressions, which can be used for 
modeling in many systems (such as ILOG Solver [10]). In contrast to views, these 
expressions are not used for propagation directly and, like indexicals, yield no 
completeness guarantees. 

6 Set Variables: Channeling 

Set constraints deal with variables whose domains are sets of finite sets. This 
powcrsct lattice is a Boolean algebra, so typical constraints are constructed from 
the Boolean primitives disjunction (union), conjunction (intersection), and nega- 
tion (complement), and the relations equality and implication (subset). 

Transformation and Specialization. As for Boolean and integer variables, 
views on set variables enable transformation and specialization. Using comple- 
ment views (analogous to Boolean negation) on x, y, z with a propagator for 
x l~l y = z yields a propagator for x U y — z. A complement view on y gives us 
x\y = z. Constant views like the empty set or the universe enable specialization; 
for example, xC\y — z implements set disjointness if z is the constant empty set. 

Channeling views. A channeling view changes the type of the values that a 
variable can take. Our model already accommodates for this as a view ip x maps 
elements between different sets Vol and Val' . 

An important channeling view is a singleton view on an integer variable x, 
defined as tp x (v) = {v}. It presents an integer variable as a singleton set variable. 
Many useful constraints involve both integer and set variables, and some of them 
can be expressed with singleton views. The simplest constraint is x € y, where x 
is an integer variable and y a set variable. Singleton views let us implement it as 
{x} C y. and just as easily give us the negated and reified variants. Obviously, 
this extends to {x} o y for all other set relations o. 
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Singleton views can also be used to derive pure integer constraints from set 
propagators. For example, the constraint same([a;i, . . . , x n ], [yi, . . . , y m ]) states 
that the two sequences of integer variables take the same values. With singleton 
views, UILiI 2 ^} = UJli{2/j} implements this constraint. 

Channeling between domain implementations. Most systems approxi- 
mate finite set domains as convex sets defined by a lower and an upper bound [7] . 
However, Hawkins ct al. [8] introduced a complete representation for the do- 
mains of finite set variables using ROBDDs. Channeling views can translate 
between interval- and ROBDD-based implementations. We can derive a propa- 
gator on ROBDD-based variables from a set-interval propagator, and thus reuse 
set-interval propagators for which no efficient ROBDD representation exists. 

7 Extended Properties of Derived Propagators 

This section discusses how views can be composed, how derived propagators 
behave with respect to idempotence and subsumption, and how events can be 
used to schedule derived propagators. Finally, we discuss the relation between 
views and path consistency. 

Composing views. A derived propagator permits further derivation: tp(tp'(p)) 
for two views tp, tp' is perfectly acceptable, properties like correctness and com- 
pleteness carry over. For instance, we can derive a propagator for x — y = c from 
a propagator for x + y = by combining an offset view and a minus view on y. 

Idempotent propagators. A propagator is idempotcnt iff p(p(d)) = p{d) for 
all domains d. Some systems require all propagators to be idempotent, others 
apply optimizations if the idempotence of a propagator is known [11]. If a propa- 
gator is derived from an idempotent propagator, the result is idempotent again: 

Theorem 6. If p(p(d)) = p(d) for a propagator p and a domain d, then, for any 
view tp, p{p)(tp(p)(d)) = tp(p){d). □ 

Proof. Function composition is associative, so we can write tp(p)(tp(p)(d)) as 
tp" opo (tpo(p~) opoip(d). We know that pop" = id for all domains that contain 
only assignments on which tp~ is fully defined, meaning that = |d|. As we 

first apply tp, this is the case here, so we can remove tpotp~ , leaving tp~ opopoip(d). 
As p is idempotent, this is equivalent to p~ opo tp(d) = tp{jp)(d). ■ 

Subsumption. A propagator is subsumed for a domain d iff for all stronger 
domains d! C d, p(d') = d' . Subsumed propagators do not contribute any prop- 
agation in the remaining subtree of the search, and can therefore be removed. 
Deciding subsumption is coNP-complete in general, but for most propagators an 
approximation can be decided easily. This can be used to optimize propagation. 

Theorem 7. p is subsumed by tp{d) iff tp(p) is subsumed by d. □ 



12 



Proof. The definition of ip gives us that W C d. if~ (p(if(d'))) = d' is equiv- 
alent with yd' C d. if~ (p(ip(d'))) = if~{if{d'). As f~ is a function, and 
because it is contraction-preserving (see Theorem 3), this is equivalent with 
\/d' C d. p(if(d')) — (f(d'). Because all <f(d') are subsets of ip(d), we can rewrite 
this to Vd" C f(d). p(d") = d", concluding the proof. ■ 

Events. Many systems control propagator invocation using events (for a de- 
tailed discussion, see [11]). An event describes how a domain changed. Typi- 
cal events for finite domain integer variables are: the variable x becomes fixed 
(fix(cc)); the lower bound of variable x changes (lbc(a;)); the upper bound of vari- 
able x changes (ubc(x)); the domain of variable x changes (dmc(x)). In some 
systems, lbc(a;) and ubc(x) are collapsed into one event, bc{x) = lbc(x) Vubc(x). 
Events are monotone: if events(d, d") is the set of events occurring when the 
domain changes from d to d" (with d" C d), then we have events(d, d") = 
events(d, d') U events(d', d") for any d" C d' C d. Propagators are associated 
with event sets: A propagator p depends on an event set es(p) iff 

1. for all d if p(d) ^ p(p(d)), then events(d,p(d)) fl es{p) ^ 

2. for all d, d' where p(d) = d, d' C d, p(d') ^ d' , then events(d, d') n es(p) ^ 

If a propagator p depends on es(p), what event set does ^(p) depend on? We 
can construct a safe approximation of es(f(p)): If fix(x) G es(p), put fix(x) G 
es(</?(p)). For any other event e G es(p) 7 put dmc(a;) G es(<j5(p)). This is correct 
because (/^ is injective. If is monotone with respect to the order on Val x , 
a < b => if x (a) < ip x {b), we can also use bounds events. If is anti- monotone 
with respect to that order, we have to switch lbc with ubc. 

Arc and path consistency. Instead of regarding a view if as transforming a 
constraint c, we can regard ip as additional constraints, implementing the decom- 
position. Assuming Var = {x\, . . . , x n }, we use additional variables x[, . . . , x' n . 
Instead of c, we have c' = c[xi/x[, . . . , x n /x' n ], which enforces the same relation 
as c, but on x\. . .x' n . Finally, we have n view constraints c v _i, each equivalent 
to the relation fi(xi) = x\. The solutions of the decomposition model, restricted 
to the X\ . . . x n , are exactly the solutions of the original view-based model. 

Example. Assume the equality constraint c = (x = y). In order to propagate 
c' = (x = y + 1), we could use a domain complete propagator p for c and a 
view if with f x (v) = v, ip y (v) = v + 1. The alternative model would be defined 
with additional variables x' and y' , a view constraint c VtX for x' = x, a view 
constraint c^y for y' — 1 = y, and c[x/x' ,y/y'}, yielding x' = y' . □ 

Every view constraint c v> i shares exactly one variable with c and no variable 
with any other c v ^. Thus, the constraint graph is Berge-acyclic, and we can reach 
a fixpoint by first propagating all the c Vt i, then propagating c\x\jx' x , . . . , x n /x'n], 
and then again propagating the c^j. This is exactly what ip~ opoip does. In this 
sense, views can be seen as a way for specifying a perfect order of propagation, 
which is usually not possible in constraint programming systems. 

If <f(p) is domain complete for ip~(c), then it achieves path consistency for 
c\x\jx' x , . . . ,x n /x' n ] and all the c v ^ in the decomposition model. 
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8 Limitations 



Although views are widely applicable, they are no silver bullet. This section 
explores some limitations of the presented architecture. 

Beyond injective views. Views as defined in this paper are required to be 
injective. This excludes some interesting views, such as a view for the absolute 
value of a variable, or a view of a variable modulo some constant. None of the 
basic proofs makes use of injectivity, so non-injective views can be used to derive 
(bounds) complete, correct propagators. 

However, event handling changes when views are not injective: 

— A domain change event on a variable does not necessarily translate to a 
domain change event on the view. For instance, given a domain d with d(x) = 
{ — 1, 0, 1}, removing the value —1 from x is a domain change event on x, but 
not on abs(x). 

— A domain change event on a variable may result in a value event on the 
view. For instance, removing instead of —1 in the above example results 
in d(x) = { — 1, 1}, but in abs(a;) there is only a single value left. 

These effects may lead to unnecessary propagtor invocations, or even to in- 
correct behavior if a propagator relies on the accuracy of the reported event. 
As propagators in Gecode may assume that events are crisp in this sense, we 
decided not to allow non-injective views. 

Multi-variable views. Some multi-variable views that seem interesting for 
practical applications do not preserve contraction, for instance a view on the 
sum or product of two variables. The reason is that removing a value through 
the view would have to result in removing a tuple of values from the actual 
domain. As domains can only represent cartesian products, this is not possible 
in general. For views that do not preserve contraction, Theorem 7 does not hold. 
That means that a propagator p cannot easily detect subsumption any longer, 
as it would have to detect it for (p(jj) instead of just for itself, p. In Gecode, 
propagators report whether they are subsumed, so that they are not considered 
for propagation again. This optimization is vital for performance, so we only 
allow contraction-preserving views. 

For contraction-preserving views on multiple variables, all our theorems still 
hold. Some useful views we could identify arc 

— A set view of Boolean variables [b\, . . . , b n ], behaving like {i \ bi = 1}. 

— An integer view of Boolean variables [bi , . . . , b n ] , where bi is 1 iff the integer 
has value i. 

— The inverse views of the two views above. 

These views are of limited use, and the decomposition approach will probably 
work just as well in these cases. 
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Table 2. Applicability of views: number of generic vs. derived propagators 



Variable type 


Generic propagators 


Derived propagators 


Ratio 


Integer 


69 


230 


3.34 


Boolean 


23 


72 


3.13 


Set 


24 


114 


4.75 


Overall 


116 


416 


3.59 



Propagator invariants. Propagators typically rely on certain invariants of a 
variable domain implementation. If idempotence or completeness of a propagator 
depend on these invariants, channeling views lead to problems, as the actual 
variable implementation behind the view may not respect the same invariants. 

For example, a propagator for interval-based finite set variables can assume 
that adjusting the lower bound of a variable does not affect its upper bound. 
If this propagator is instantiated with a channeling view for an ROBDD-based 
set variable, this invariant is violated: if, for instance, the current domain is 
{{1,2}, {3}}, and you add 1 to the lower bound, the 3 is removed from the 
upper bound (in addition to 2 being added to the lower bound). A propagator 
that relies on the invariant may lose idempotence. 

9 Experiments 

Our experiments in [12] showed that deriving propagators using views incurs no 
runtime overhead. Here, we present empirical evidence for two more facts: views 
are highly applicable in real- world constraint programming systems, and they 
are clearly superior to a decomposition-based approach. 

Applicability. The Gecode C++ library [5] makes heavy use of views. Table 2 
shows the number of generic propagators implemented in Gecode, and the num- 
ber of derived instances. On average, every generic propagator results in 3.59 
propagator instances. Propagators in Gecode account for more than 40000 lines 
of code and documentation. As a rough estimate, generic propagators with views 
save around 100 000 lines of code and documentation to be written, tested, and 
maintained. On the other hand, the views are implemented in less than 8 000 
lines of code, yielding a 1250% return on investment. 

Views vs. decomposition. In order to relate derived propagators to arc and 
path consistency, Sect. 7 decomposed a derived propagator (p(p) into additional 
variables and propagators for the individual ip x and p. Of course, one has to ask 
why we advertise variable views instead of always using decomposition. Table 3 
shows the runtime and space requirements of several benchmarks implemented in 
Gecode. The numbers were obtained on a Intel Pentium IV at 2.8 GHz running 
Linux and Gecode 2.1.1. The figures illustrate that derived propagators clearly 
outperform the decomposition, both in runtime and space. 
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Table 3. Runtime and space comparison: derived propagators vs. decomposition 



Benchmark 


derived 


decomposed 




time (ms) 


space (kB) 


relative time (%) 


relative space (%) 


Alpha 


91.25 


83.22 


405.62 


167.32 


Eq-20 


1.37 


70.03 


613.61 


219.95 


Queens 100 


24.72 


2110.00 


705.10 


103.03 


Golf 8-4-9 


310.40 


10 502.00 


211.47 


231.64 


Steiner triples 9 


135.72 


957.03 


108.38 


100.03 



10 Conclusion and Future Work 

The paper has developed variable views as a technique to derive perfect prop- 
agator variants. Such variants are ubiquitous, and the paper has shown how 
to systematically derive propagators using techniques such as transformation, 
generalization, specialization, and channeling. 

We have presented a model of views that allowed us to prove that derived 
propagators are indeed perfect: they inherit correctness and domain complete- 
ness from their original propagator, and preserve bounds completeness given 
additional properties of views. 

As witnessed by the empirical evaluation, deriving propagators saves huge 
amounts of code to be written and maintained in practice, and is clearly superior 
to decomposing constraints into additional variables and simple propagators. 

For future work, it will be interesting to investigate how views can be gener- 
alized, even if that means that derived propagators are not perfect any more. 

Acknowledgements. We thank Mikael Lagerkvist and Gcrt Smolka for fruitful 
discussions about views and helpful comments on a draft of this paper. 

References 

1. K. Apt. Principles of Constraint Programming. Cambridge University Press, 2003. 

2. F. Bcnhamou. Heterogeneous Constraint Solving. In Proceedings of the fifth Inter- 
national Conference on Algebraic and Logic Programming (ALP'96), volume 1139 
of LNCS, pages 62-76. Springer, 1996. 

3. M. Carlsson, G. Ottosson, and B. Carlson. An open-ended finite domain constraint 
solver. In H. Glaser, P. H. Hartel, and H. Kuchen, editors, Programming Languages: 
Implementations, Logics, and Programs, 9th International Symposium, PLILP'97, 
volume 1292 of LNCS, pages 191-206, Southampton, UK, 1997. Springer. 

4. C. W. Choi, W. Harvey, J. H. M. Lee, and P. J. Stuckey. Finite domain bounds 
consistency revisited. In A. Sattar and B.-H. Kang, editors, AI 2006: Advances in 
Artificial Intelligence, volume 4304 of LNCS, pages 49-58. Springer, 2006. 

5. Gecode: Generic constraint development environment, 2008. Available as an open- 
source library from www.gecode.org. 

6. I. P. Gent, C. Jefferson, and I. Miguel. Watched literals for constraint propagation 
in Minion. In F. Benhamou, editor, Twelfth International Conference on Principles 



Hi 



and Practice of Constraint Programming, volume 4204 of LNCS, pages 182-197, 
Nantes, France, 2006. Springer. 

7. C. Gervet. Interval propagation to reason about sets: Definition and implementa- 
tion of a practical language. Constraints, l(3):191-244, 1997. 

8. P. Hawkins, V. Lagoon, and P. Stuckey. Solving set constraint satisfaction problems 
using ROBDDs. J. Artif. Intell. Res. (J AIR), 24:109-156, 2005. 

9. M. J. Maher. Propagation completeness of reactive constraints. In ICLP '02: 
Proceedings of the 18th International Conference on Logic Programming, volume 
2401 of LNCS, pages 148-162, London, UK, 2002. Springer. 

10. J.-F. Puget and M. Leconte. Beyond the glass box: Constraints as objects. In 
J. Lloyd, editor, Proceedings of the International Symposium on Logic Program- 
ming, pages 513-527, Portland, OR, USA, Dec. 1995. The MIT Press. 

11. C. Schulte and P. J. Stuckey. Efficient constraint propagation engines. Transactions 
on Programming Languages and Systems, 2008. To appear. 

12. C. Schulte and G. Tack. Views and iterators for generic constraint implementations. 
In Recent Advances in Constraints (2005), volume 3978 of LNAI, pages 118-132. 
Springer, 2006. 

13. P. Van Hentenryck, V. Saraswat, and Y. Deville. Design, implementation, and 
evaluation of the constraint language cc(FD). The Journal of Logic Programming, 
37(1-3): 139-164, Oct. 1998. 



17 



